As data management applications become more advanced and complicated, the physical tracking and mapping of an application in a network storage system becomes increasingly difficult. Furthermore, the entire process of provisioning an application has become unduly burdensome on administrators. During conventional application provisioning, the application administrator is required to decide where on a cluster a new application instance should be provisioned. Further, the administrator has to determine and implement the performance, capacity and protection characteristics of all the components of the application being provisioned. In addition, the administrator must determine the available performance and capacity headroom on the network storage system cluster and the protection capabilities of the network storage system cluster. Based on the available performance and capacity headroom on the network storage system cluster and the protection capabilities of the network storage system cluster, the administrator must decide the aggregates on which the application will be provisioned. Furthermore, the administrator has to create the appropriate number of volumes and LUNs (logical unit numbers) to obtain the optimal experience from the application.
In order to effectively provision an application, the administrator needs to be familiar with the specific network storage system storage terminology and storage administration. The administrator also needs backend infrastructure expertise to know which commands are required to run, and what options need to be set. Typically, an application is made up of multiple components (e.g. database files and logs). Often provisioning of a single component can fail, thus requiring the administrator to manually clean up any other application components that were previously provisioned.
Once an application has been successfully provisioned by the administrator, there exists no convenient process to determine which storage components and protocol components are utilized by the application. For example, where a specified number of volumes and LUNs are designated to act as storage for an exemplary application, after provisioning the application, the network storage system does not provide which volumes, LUNs and igroups are in use by the application. An igroup is a logical named entity that is assigned to one or more addresses associated with one or more initiators.
Conventional network storage systems provide data management functionality at the granularity of the volume or the file system. However, the storage elements of an application may span across one or more such volumes or file systems and the network storage system does not provide data management functionality at the granularity of an application instance. Keeping track of the mapping between storage and application is the responsibility of the application administrator. Because the network storage system does not track the mapping between the application and the storage components in use by that application, the network storage system cannot provide any application level reporting. Thus, the network storage system is unable to report how much storage capacity is in use by the application, or how many IOPS (“I/O operations per second”) are being consumed by the application.
The present disclosure is susceptible to various modifications and alternative forms, and some representative embodiments have been shown by way of example in the drawings and will be described in detail herein. It should be understood, however, that the inventive aspects are not limited to the particular forms illustrated in the drawings. Rather, the disclosure is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the disclosure as defined by the appended claims.